Docker
Docker 是一個建立在本地端的虛擬環境,讓我們可以快速的建立、測試跟部署應用程式。
更細一點說的話
Docker 將軟體封裝到名為容器的標準化單位,其中包含程式庫、系統工具、程式碼和執行時間等執行軟體所需的所有項目。使用 Docker,您可以將應用程式快速地部署到各種環境並加以擴展,而且知道程式碼可以執行。—— AWS
- dockerfile
- build
- FROM、RUN、POINT
- image
- container
Heroku
- 部署用
- port 不寫死,寫成環境變數
const port = process.env.PORT || 3000
- 設定 NODE 版本,不是必須,但是個好習慣唷
淺淺淺淺淺談那些你在前端實作時看到的名詞們
MVC
- Model:模型,負責處理資料、演算法、商業邏輯等等。
- View:視圖:欲呈現的畫面。
- Controller:控制器,控制、處理使用者的請求(request)。
SSR
伺服器渲染(Server-Side Rendering)
但當專案龐大時易造成前後端混合的程式碼混亂,於是把前後端分開來實作,但分開後,又發現
- 頁面由伺服器產生,每次更新頁面都需要全畫面重新渲染。
- 伺服器取得資料後,需要計算畫面並整頁送出,運算及流量的負荷都太大。
每次 render 頁面時的使用者體驗不好,直到 Gmail 使用的 SPA 方式解決了這樣的問題。
SPA
單頁式應用(Single Page Application)
雖然 SPA 可以讓使用者重載新頁面時不會有全空白之類的畫面,解決了上面提到的那些問題,可是這樣一來前端就要開始負責取得資料、處理畫面、頁面跳轉
的阿哩阿雜的問題了.... 於是.... 沒錯!有人就把 MVC 的概念搬來前端實作了!
SPA more
空殼 HTML 所以 SEO 極差
解決辦法
SPA 的問題只在第一畫面,那就在伺服器先算好第一畫面,其他畫面再透過 JavaScript 動態處理;也就是第一畫面為 SSR,其他畫面是 CSR(Client-Side Rendering),這樣是不是就完美了呢?
這樣做的代價,就是同一個頁面需要實作兩次顯示邏輯(前端後端各一次);幸好 JavaScript 不是一個純粹前端的語言,後端可以跑在 Node.js 中,開發者得以使用大致相同的程式,實現這樣的需求;這種同一份 JavaScript Code 可以跑在前端與後端的程式設計,叫做 Isomorphic JavaScript,同構的 JS。
在這樣的概念出來後,前端框架的 SSR 框架也就應運而生了,例如 React 的 Next,及 Vue 的 Nuxt,都是原本前端框架的語法再擴充,讓原先就熟悉框架的開發者,只需要越過相對小的進入門檻,就能滿足第一頁 SSR 的需求。
除了透過 SSR 框架幫你把頁面的第一次渲染即時算出來,在一些資料相對簡單,變動不太大的網站,也可以選擇透過例如 Prerender 之類的工具,是先把網頁全部算好,儲存成靜態頁面,這樣也可以解決 SEO 的問題。
藉由 Isomorphic JavaScript 的設計,及 Prerender 等工具,第一畫面才會出現的問題就能被解決,關於 SPA 及 SSR 的優缺點取捨,自然也就再也不是問題。
跟自己對不起,我放棄消化成速記了 XD
跟上流行,所以來點微心得
- 許多當前火熱的技術與名詞其實都與當下的時空背景跟技術限制有關。
- 學到有趣的字:壞味道。
- 一坑接一坑,接完一坑再一坑,後續工作不會讓自己亂入坑,以目的性為主學習,但要把每個坑填好填滿。
- 前端三十 - 成為更好的前端工程師 覺得這系列還不錯,算是新手能上手、篇幅也好消化的系列文,對 JS 基礎上手很有幫助
前人種樹
為什麼現在的前端都在用「框架」?
談談前端框架
為什麼網站要做成 SPA?SSR 的優點是什麼?
前後端分離與 SPA
图解 SSR 等 6 种前端渲染模式
前端 SSR 技術探究